Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 2/csmp-v2-003.txt

Text File | 1995-06-30 | 59KB | 1,733 lines

C.S.M.P. Digest             Mon, 11 Jan 93       Volume 2 : Issue 3

Today's Topics:

    need Sys6 InForeground() technique
    In search of SYNCHING code
    pbhopendf returns -50?
    TCL: What Are They Trying to Say?
    'appe' File Type
    Just for you, an early Christmas present
    Adding Comm to an Application



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, there is
no way that I know of for you to post articles to the group.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Kenneth Hughes)
Subject: need Sys6 InForeground() technique
Organization: School of Computer Science, Carnegie Mellon
Date: Mon, 7 Dec 1992 23:23:31 GMT

I'm running the attached routine within a trap patch to determine if the
current application is the front application.  It's time to make the code
work under System 6, so I need a technique for determining this without the
benefit of System 7's Process Manager routines.  Note that I cannot use the
usual approach of maintaining a gInForeground variable by toggling it as the
suspend/resume events come in since I'm in a patch, not my own application.
I need to handle apps that may not handle suspend/resumes themselves.
    What's the best way to do this?  I have a feeling that it's necessarily
messy.  Although I'd prefer a clean solution, I'm not proud.  :-)

Boolean
InForeground(void)
{
    ProcessSerialNumber    curPSN,frontPSN;
    long                   response;
    Boolean                inForeground;

    if ((TrapAvailable( _GestaltDispatch)) &&
        (Gestalt(gestaltOSAttr, &response) == noErr) &&
        (response && gestaltLaunchControl) ) {

        (void) GetCurrentProcess(&curPSN);        // Always returns noErr
        switch(GetFrontProcess(&frontPSN)) {
            case noErr:
                if (SameProcess(&curPSN,&frontPSN,&inForeground) == noErr)
                    return(inForeground);
                break;
            case paramErr:
            case procNotFound:
                break;
            default:
                DebugStr("\pUnexpected value returned from GetFrontProcess.");
        }  // change "switch" to "if" later.
        return(FALSE);
    } else {
        //
        //
        DebugStr("\pHow can we tell if we're in the foreground under Sys 6?");
        //
        //
    }
}
Thanks for any help.

Kenneth J. Hughes
Entelechy Corporation

+++++++++++++++++++++++++++

From: [e-mail] (Chris Wysocki)
Date: 8 Dec 92 17:59:40 GMT
Organization: Connectix Corporation, San Mateo, CA

In article <[e-mail]> [e-mail] (Kenneth Hughes) writes:

>I'm running the attached routine within a trap patch to determine if the
>current application is the front application.  It's time to make the code
>work under System 6, so I need a technique for determining this without the
>benefit of System 7's Process Manager routines.

Apple started to document the internal workings of MultiFinder,
including MultiFinder equivalents of many of the System 7 Process
Manager routines, in Tech Note 299, but then decided not to release
it.  Fortunately, a few copies of TN299 did manage to sneak out, and I
managed to get my hands on a copy of a copy of a copy, so here's the
information you need:

According to TN 299, a MultiFinder 6.0.x process information record
looks like:

typedef struct {
    short           processState;               /* process state */
    short           processID;                  /* process id */
    OSType          processType;                /* type of process (usually 'APPL') */
    OSType          processSignature;           /* signature of process */
    long            processVersion;             /* version of process */
    THz             processZone;                /* pointer to minor zone */
    unsigned long   processMode;                /* process' created mode */
    Boolean         processNeedSusResEvts;      /* expects suspend/resume events */
    Boolean         processBack;                /* can accept background time */
    Boolean         processActivateOnResume;    /* will activate/deactivate on suspend/resume */
    short           processDad;                 /* process id of my dad */
    unsigned long   processSize;                /* size of his world */
    unsigned long   processStackSize;           /* size of his stack */
    unsigned long   processSlices;              /* # of times process has CPU */
    unsigned long   processFreeMem;             /* amount of free memory in heap */
    Str32           processName;                /* name of backing app */
    short           processVRefNum;             /* vRefNum of app res file */

} MFProcessInfoRec;

I won't list all the routines here, but the relevant ones for your
purposes are:

#define MFA5        0x0B7C      /* lo-mem global containing MF A5 value */
#define FrontPID    0xFFFFF7CE  /* offset of front process ID from MF A5 */

pascal short MFGetCurrentProcess()
    = { 0x3F3C, 0x0013, 0xA88F };
pascal short MFGetProcessInformation(short PID, MFProcessInfoRec *procInfo)
    = { 0x3F3C, 0x0017, 0xA88F };

pascal short MFGetFrontProcess()
{
    return (*((short *)(*MFA5+FrontPID)));
}

Once you've ascertained that you're running under System 6.0.x with
MultiFinder, you should be able to determine if the current process is
the front process simply by checking if MFGetCurrentProcess() ==
MFGetFrontProcess().

Chris.
- --
- ------------------------------------------------------------------------------
Chris Wysocki                                     Internet: [e-mail]
Software Engineer                                   America Online: AFA ChrisW
Connectix Corporation                                   CompuServe: 72010,1140

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: 9 Dec 92 02:20:09 GMT
Organization: Project GLUE, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Chris Wysocki) writes:
>
>I won't list all the routines here, but the relevant ones for your
>purposes are:
>
>#define MFA5        0x0B7C      /* lo-mem global containing MF A5 value */
>#define FrontPID    0xFFFFF7CE  /* offset of front process ID from MF A5 */
>
>pascal short MFGetCurrentProcess()
>    = { 0x3F3C, 0x0013, 0xA88F };
>pascal short MFGetProcessInformation(short PID, MFProcessInfoRec *procInfo)
>    = { 0x3F3C, 0x0017, 0xA88F };
>
>pascal short MFGetFrontProcess()
>{
>    return (*((short *)(*MFA5+FrontPID)));
>}
>
>Once you've ascertained that you're running under System 6.0.x with
>MultiFinder, you should be able to determine if the current process is
>the front process simply by checking if MFGetCurrentProcess() ==
>MFGetFrontProcess().

Don't believe everything you read in an unreleased tech note.
Specifically, MFGetFrontProcess simply won't compile as written.

replace the 'return' line with
    return (*((short *)((*(long *)MFA5)+FrontPID)));

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

---------------------------

From: [e-mail] (M. Scott Smith)
Subject: In search of SYNCHING code
Organization: The Great Beyond
Date: Mon, 7 Dec 1992 22:58:00 GMT

Maybe my subjects aren't good enough?  I don't know.  It just seems <sulk>
everyone ignored me when I posted problems I was having getting in sync with
the monitor, for smooth graphics, etc.

So, like any netter, I'm doing the logical thing.  I'm asking again!  :)

Ok, I want to sync to the monitor.  There's nice sample code in the Internet
Mac Programmer's Guide on sumex (or whatever it's called,) except that it
doesn't seem to work.

I could hack around with it a bit (well, I already have), but I haven't even
heard the code works (with System 7?  Period?) so I don't want to run around
in circles.

So, please, if you have any sample code for synching to the monitor, or
if you know that the code I'm referring to either works or doesn't work, pass
that info along.

And if you don't, well, I'll just have to start posting exotic subjects
which will result in more people reading my message and more people not
responding.  :)

Thanks in advance for any help..

M. Scott Smith
  ([e-mail])


+++++++++++++++++++++++++++

From: [e-mail] (John Werner)
Date: 8 Dec 92 01:51:50 GMT
Organization: UC Berkeley School of Education

In article <[e-mail]>, M. Scott Smith wrote:

> So, please, if you have any sample code for synching to the monitor, or
> if you know that the code I'm referring to either works or doesn't work, pass
> that info along.

I have some code I whipped up last week, but it's part of a MacApp/C++
program, so it probably wouldn't do you much good.  But it wasn't that hard
to do; it only took me an hour or so do do a nice general solution.  Here's
what you need to do:

1) Set up a task record for your VBL task.  The task needs to run at every
VBL interrupt (vblCount = 1).  The vblAddr field needs to point to a
function that you write...

2) The function's job is to increment a counter somewhere, then set
vblCount back to 1.  The counter can be a global variabIe, which means you
have to worry about setting/restoring A5, since it isn't valid at interrupt
time.  I decided to be clever and put my counter inside the task record
itself; this way I didn't have to mess with A5 at all.  I just stash away a
pointer to the task record so I can get to the counter later when I need to
draw.  (C++ note: my task record is actually a pointer-based C++ object,
complete with constructor and other methods.)

3) Install the task.  If SlotVInstall is available, you need to figure out
which monitor you're dealing with.  Find the GDevice that contains the
largest piece of your window/view/whatever.  You can walk the device list
yourself, or use DeviceLoop to do it for you.  Then use SlotVInstall to
install it.  If SlotVInstall isn't available, you don't have to worry about
devices; just use VInstall.

4) When it's time to draw something, get the value of the counter, then sit
in a tight loop until the counter changes, e.g.
    // Wait for the counter to change
    long oldCount = theRec->counter;
    while (theRec->counter == oldCount)
        ;
Then do your drawing.

5) Remember to remove the task with SlotVRemove or VRemove when you're
done.


- --
John Werner                         [e-mail]
UC Berkeley School of Education     510-642-9651

+++++++++++++++++++++++++++

From: [e-mail] (Michael A. Kelly)
Organization: High Risk Ventures
Date: Tue, 8 Dec 1992 03:58:09 GMT


In article <[e-mail]> you write:
>Maybe my subjects aren't good enough?  I don't know.  It just seems <sulk>
>everyone ignored me when I posted problems I was having getting in sync with
>the monitor, for smooth graphics, etc.

Oh, waahh!

Here you go:

/*
 * VBLSync.h
 *
 */


#ifndef _H_VBLSync
#define _H_VBLSync



// Error codes

/* None */



// Global variables

#ifdef VBLSyncSource

long            gVblCounter;        // The VBL counter

#else VBLSyncSource

extern long     gVblCounter;        // The VBL counter

#endif VBLSyncSource



// Function prototypes

void InstallSync( GDHandle theDevice );
void RemoveSync( void );
void WaitForSync( void );




#endif _H_VBLSync






/*
 * VBLSync.c
 *
 *    Implements a VBL counter on any Mac.
 *
 *    Usage:
 *        InstallSync();
 *        ...
 *        WaitForSync();
 *        CopyBits(...);
 *        ...
 *        RemoveSync();
 *
 */


#define VBLSyncSource

#include "VBLSync.h"



typedef struct {

    long        goodA5;
    VBLTask     task;
    long        slot;

}    VideoBlank;



static VideoBlank    blank;




static pascal void DoTask( void );





/*
 * DoTask
 *
 */

static pascal void DoTask()
{

    long        oldA5;
    VideoBlank  vbltask;

    asm {

        MOVE.L    A5, oldA5     ; save off the old value of A5
        MOVE.L    -4(A0), A5    ; A0 points to our VBL task record, and
                                ; earlier we saved CurrentA5 near it

    }

    ++ gVblCounter;

    blank.task.vblCount = 1;    // run again as soon as possible

    asm {
        MOVE.L    oldA5, A5
    }

}




/*
 * InstallSync
 *
 */

void InstallSync(
    GDHandle    theDevice )
{

    AuxDCEHandle    driver;

    blank.goodA5 = (long) CurrentA5;
    gVblCounter = 0;

    blank.task.qType = vType;
    blank.task.vblAddr = (ProcPtr) DoTask;
    blank.task.vblCount = 1;
    blank.task.vblPhase = 0;

    driver = (AuxDCEHandle) GetDCtlEntry( (*theDevice)->gdRefNum );
    blank.slot = (*driver)->dCtlSlot;

    SlotlVInstall( (QElemPtr) &blank.task, blank.slot );

}




/*
 * RemoveSync
 *
 */

void RemoveSync()
{

    SlotVRemove( (QElemPtr) &blank.task, blank.slot );

}




/*
 * WaitForSync
 *
 */

void WaitForSync()
{

    long    counter = gVblCounter;

    while ( counter == gVblCounter );

}




- --
_____________________________________________________________________________
Michael A. Kelly                                               Senior Partner
[e-mail]                                      High Risk Ventures
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: Chris Verret <[e-mail]>
Date: 9 Dec 92 14:36:45 GMT
Organization: Vrije Universiteit Brussel

In october the thread "Best way to get A5 into VBLTaskProc?" was
posted on comp.sys.mac.programmer. Several answers were given:
self-modifying code, sticking A5 right next to the VBLTask and using
SetA5,...
I was just experimenting with the first one myself, when Tim Dierks
followed up the thread and hinted me towards another, more elegant
solution. Hope he don't mind me quoting him:

>In fact, if you didn't want to screw around with A5 and all that other
>garbage, you could just set up your structure like this:
>
>typedef struct {
>    VBLTask     gTask;
>    long        gVBLCount;
>} MyVBLTask;
>
>and mess with the variable directly; this way, you don't use globals,
>so you don't have to sweat the whole A5 thing.

This is how I did it:

typedef struct {
    VBLTask            task;
    short                videoslot;
    long                count;
} VBLCounterRec;

VBLCounterRec VBLCounter;

/************************************************************/

Boolean InstallVBLCounter(void)
{
    DefVideoRec            VBLVideoDefault;

    VBLCounter.task.vblAddr = VBLCounterProc;
    VBLCounter.task.qType = vType;
    VBLCounter.task.vblCount = 1;
    VBLCounter.task.vblPhase = 0;

    GetVideoDefault(&VBLVideoDefault);
    VBLCounter.videoslot = VBLVideoDefault.sdSlot;

    VBLCounter.count = 0;

    return (SlotVInstall((QElemPtr)&VBLCounter.task, VBLCounter.videoslot)
== noErr);
}

/************************************************************/

Boolean RemoveVBLCounter(void)
{
    return (SlotVRemove((QElemPtr)&VBLCounter.task, VBLCounter.videoslot) ==
noErr);
}

/************************************************************/

pascal void VBLCounterProc(void)
{
    asm {
        MOVE.W    #1, OFFSET(VBLCounterRec, task.vblCount) (A0)
        ADDQ.L    #1, OFFSET(VBLCounterRec, count) (A0)
    }
}

TN 180 : "...on entry into the VBL task, A0 points to the
theVBLTask field in the VBLRec record, which is the first field in the
record..."

Good Luck!

---------------------------

From: [e-mail] (Kevin Cutts)
Subject: pbhopendf returns -50?
Date: 8 Dec 92 14:28:56 GMT
Organization: Motorola Microcomputer, Schaumburg, IL

with error code = -50. According to IM (both V4 and files) this routine
can't return -50! I am zeroizing the pb block before the call and setting
the required values from an sfreply structure. This bug only happens for
one of my users. He is using sys6.0.8 running on a IIci. I looked at his
init's but didn't see anything strange. My code is developed using Think C
version 5.0.4. I looked at some of the related calls in the toolbox
that can return a -50 but can't get a clue.
Any help?

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 8 Dec 92 20:56:18 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (Kevin Cutts) wrote:
>
> with error code = -50. According to IM (both V4 and files) this routine
> can't return -50! I am zeroizing the pb block before the call and setting
> the required values from an sfreply structure. This bug only happens for
> one of my users. He is using sys6.0.8 running on a IIci. I looked at his
> init's but didn't see anything strange. My code is developed using Think C
> version 5.0.4. I looked at some of the related calls in the toolbox
> that can return a -50 but can't get a clue.
> Any help?

The error list given with a function should not be regarded as complete;
a number of traps can return other codes for various reasons; the list
is only intended to give you a list of unique things that might happen
which you might wish to specifically check for.  In this case, you've
found out that traps which are dispatched (where several calls share a
trap and are distinguished by a value, usually passed in D0 or on the
stack) return paramErr when you pass a selector they don't understand.

In this case, you're calling HOpenDF, which is a routine which uses
the trap _HFSDispatch with selector $1A, under System 6.0.8 when
it is only supported under System 7.  Because the 6.0.8 HFSDispatch
doesn't understand selector $1A, it returns paramErr.

Solution: only use PBHOpenDF under System 7 or later.  There's no
specific Gestalt selector for determining if it is available; mosst
people just check to see if the gestaltHasFSSpecCalls bit is set
in the response to the gestaltFSAttr selector.  (Or you could just
try calling it, and if it returns -50, calling PBHOpen instead.)

Hope this helps (TM)
Tim Dierks

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 9 Dec 92 00:07:09 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Kevin Cutts) writes:
>with error code = -50. According to IM (both V4 and files) this routine
>can't return -50!
>
    It can under one condition...

>I am zeroizing the pb block before the call and setting
>the required values from an sfreply structure.
>
    That's the condition...

    If you pass a WDRefNum (which is what you really get in the vRefNum
field of an SFReply) in the vRefNum field and you clear out all the other
fields, you can get back a -50 since this isn't a correctly formed paramBlock.

    You should use PBGetWDInfo to convert the WDRefNum into a real vRefNum
and parID and then pas them to the PBHOpenDF.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

---------------------------

From: [e-mail] (Art Urban (PROFS))
Subject: TCL: What Are They Trying to Say?
Date: 8 Dec 92 19:26:31 GMT
Organization: Atmospheric Technology Division/NCAR Boulder, CO

On page 281 of the TCL OOP Manual, CDirectorOwner makes a desperate attempt
at explaining how to implement multi-window documents. In this futile attempt,
they state "The subwindows should be owned by the document object."

Say what? CDocument only owns *one* window in the itsWindow variable. Are
they trying (poorly) to say that my subclasses of CDirector should become
dependents of CDocument, or what?

Cripes! The OOP Manual needs its own manual just to explain itself...

- --
Art Urban                            [e-mail]
===============================================================================
 "Baby trapped in film, eats own hand."                    - Joel
===============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 9 Dec 92 10:19:50 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <[e-mail]> [e-mail] (Art Urban (PROFS)) writes:

>On page 281 of the TCL OOP Manual, CDirectorOwner makes a desperate attempt
>at explaining how to implement multi-window documents. In this futile attempt,
>they state "The subwindows should be owned by the document object."

>Say what? CDocument only owns *one* window in the itsWindow variable. Are
>they trying (poorly) to say that my subclasses of CDirector should become
>dependents of CDocument, or what?

There are better refs in the Dialog Classes teach text document.

Anyway, do this:

Make your main document a CDirectorOwner, and have one CDirector
for EACH window you use. Make the "main" document CDirectorOwner
be the owner/supervisor of all the CDirectors that go with the
document (and the Application the supervisor of the CDirectorOwner)

Note that a CDirector is a subclass of a CDirectorOwner, so you
can cooly use a CDirector (or, indeed, CDocument) as "main"
CDirectorOwner.

Cheers,

                        / h+

- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.

+++++++++++++++++++++++++++

From: [e-mail] (Peter William Wieland)
Date: 8 Dec 92 22:27:14 GMT
Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

On 08-Dec-92 in TCL: What Are They Trying t..
user Art Urban @stout.atd.uca writes:
>Say what? CDocument only owns *one* window in the itsWindow variable. Are
>they trying (poorly) to say that my subclasses of CDirector should become
>dependents of CDocument, or what?
>
>Cripes! The OOP Manual needs its own manual just to explain itself...

Since you have to override CDocument anyway (as i remember, it is one of
the necessary classes to "customize"), you should probably add some more
window variables (itsPalette, itsLoadDisplay, itsWastedPtr, etc...) to
the subclass.  There should be some way to inform windows that they are
under your control (i don't really rember what it was, but...).


****************************************************************************
None of the ideas expressed above are acutally mine.  They are told to
me by Luthor and Ferdinand, the five inch tall space aliens who live
under my desk.  In return for these ideas, I have given them persmision
to eat any dust bunnies they may find under there.
Peter Wieland               [e-mail]            [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joshua Rabinowitz-Summer-91)
Organization: NASA/ARC Information Sciences Division
Date: Wed, 9 Dec 1992 23:51:13 GMT

In article <Uf9OrWa00iV4I=[e-mail]> [e-mail] (Peter William Wieland) writes:
>On 08-Dec-92 in TCL: What Are They Trying t..
>user Art Urban @stout.atd.uca writes:
>>Say what? CDocument only owns *one* window in the itsWindow variable. Are
>>they trying (poorly) to say that my subclasses of CDirector should become
>>dependents of CDocument, or what?

That your subclasses of CDIrector should have your subclass of CDoc
as their supervisor.

>>
>>Cripes! The OOP Manual needs its own manual just to explain itself...
>
>Since you have to override CDocument anyway (as i remember, it is one of
>the necessary classes to "customize"), you should probably add some more
>window variables (itsPalette, itsLoadDisplay, itsWastedPtr, etc...) to


NO!  ADD DIRECTORS!

>the subclass.  There should be some way to inform windows that they are
>under your control (i don't really rember what it was, but...).
>
>

OOOH!  I couldn't help but enter this fray, as I have BEEN THERE.

Peter -- that is wrong (I mean, problematic).  The problem
there is the owners of window, etc.
Each window must have ITS OWN DIRECTOR.  Subclass CDirector to handle each
window (that is, make aninstantiation of a CDirector (or subclass)
to handle each window.

The supervisor structure I use is:

CApp -> CDoc -> CDirector, where CDoc keeps track of the main window, and
CDirector keeps track of the 2nd window.

A format recomended to me as better, was

CApp -> CDoc -> CDirector -> mainwindow
         -> CDirector -> 2ndWindow.

that way, you can set CDoc->itsMainpPane to point at the active window pane,
which is the one that will be printed.  Also, a single call to CDoc->Close()
will close both CDirectors and each's window.


Excuse me if I was a little unclear:
summary:
each window must have it's own director (not each director need have
a window though).
- --
- ----------------------------------
#include <std/disclaimer.h>     Josh Rabinowitz, Mac TCL programmer
[e-mail]
"Me lost my cookie at the disco." -- Cookie Monster

---------------------------

From: [e-mail] (Ken B Kirksey)
Subject: 'appe' File Type
Date: 8 Dec 92 23:21:32 GMT
Organization: The World Public Access UNIX, Brookline, MA

Can anyone point me to information on the 'appe' file type?  I'm looking at
writing a background only app, and would like a little more info that is
provided in IM VI and IM:Processes (i.e. almost none:).  How is it handled
in the startup process?  When do 'appe' files in the Extensions folder
load?  Many thanks in advance.


                            Ken

+----------------------------+------------------------------------------------+
| Ken Kirksey                | "A man cannot be too careful in his choice     |
| [e-mail]     |  of enemies."                                  |
| The World, Brookline, MA   |                - Oscar Wilde                   |

- --
+----------------------------+------------------------------------------------+
| Ken Kirksey                | "A man cannot be too careful in his choice     |
| [e-mail]     |  of enemies."                                  |
| The World, Brookline, MA   |                - Oscar Wilde                   |

+++++++++++++++++++++++++++

From: [e-mail] (Lance 'Moof' Kimes)
Date: 8 Dec 92 08:29:21 GMT
Organization: University of Southern California, Los Angeles, CA


In article <[e-mail]>, [e-mail] (Ken B Kirksey) writes:
|> Can anyone point me to information on the 'appe' file type?  I'm looking at
|> writing a background only app, and would like a little more info that is
|> provided in IM VI and IM:Processes (i.e. almost none:).  How is it handled
|> in the startup process?  When do 'appe' files in the Extensions folder
|> load?  Many thanks in advance.
|>
|>
|>                             Ken
|>
|> +----------------------------+------------------------------------------------+
|> | Ken Kirksey                | "A man cannot be too careful in his choice     |
|> | [e-mail]     |  of enemies."                                  |
|> | The World, Brookline, MA   |                - Oscar Wilde                   |
|>
|> --
|> +----------------------------+------------------------------------------------+
|> | Ken Kirksey                | "A man cannot be too careful in his choice     |
|> | [e-mail]     |  of enemies."                                  |
|> | The World, Brookline, MA   |                - Oscar Wilde                   |

They're identical to normal appls except that you don't initial any managers
that use the gui(ie:window,dialog,etc). Make it accept required apple events.
All appe load alphabetically before all other programs including the finder.
Be sure to include a -1 SIZE resource that specifies background only and apple
event aware.


Lance Kimes
Systems Programmer
USC

+++++++++++++++++++++++++++

From: [e-mail] (Bas Schulte, Spider)
Date: 9 Dec 92 09:02:38 GMT
Organization: UTexas Mail-to-News Gateway

Dear Ken,

you asked:

> Can anyone point me to information on the 'appe' file
> type?  I'm looking at writing a background only app

All I can tell you is how the initialize 'THE MANAGERS' in a bg app. This is how
I do it, as compared to a standard init.:


{$IFC CompilingBgApp}
procedure InitMgrs;
begin
    InitGraf(@thePort);
    InitFonts
end;
{$ELSEC}
procedure InitMgrs;
begin
    InitGraf(@thePort);
    InitFonts;
    InitWindows;
    InitMenus;
    TEInit;
    InitDialogs(NIL);
    InitCursor;
end;
{$ENDC}

---------------------------

From: [e-mail] (David Peterson)
Subject: Just for you, an early Christmas present
Date: 2 Dec 1992 12:17:32 -0800
Organization: University of Southern California, Los Angeles, CA



Now you, the Mac programmer, can have pages of useless strings effortlessly
vomited to your screen just like your DOS and UNIX friends do.

With this dandy new MBPrintf routine you can make up printf style diagnostic
messages and have them show up in MacsBug correctly interpreted and formatted.

Okay, so this is just a little hack I threw together with a liberal amount
copyright infringment (see pg 156 of K&R). After a few hours of using it
I found it extremely useful, and it has earned a permanent place in my
personal library (not unlike every other snippet of code I come across).

Hopefully you will find it just as useful, but (as always) your mileage
may vary.

Handy tip:
    Instead of putting a '\n' at the end of your string try a semi-colon
    followed by Your Favorite MacsBug Command. ';g' is probably the most
    useful and ';s 3' will take you back to the instruction right after
    the JSR into this function. Combinations of ';dx off'/';dx on' could
    be good too.

Caveats:
    This will probably blow up if called from interupt. It makes calls
    into the StdCLib segment which may or may not be loaded.

    Probably won't work in stand alone code resources because the
    aforementioned code segment contains global data.

    I don't know what will happen if your string gets over 255 characters,
    but it probably won't be what you expected.


- -dave.

- ---------------------------

#include <StdArg.h>
#include <StdIO.h>

void MBPrintf(char* form, ...);

void
MBPrintf(char* form, ...)
{
    va_list    ap;
    char*    p;

    char*    sval;
    int        ival;
    double    dval;

    char    string[256];
    char*    strp;
    char*    strb;

    strp = &string[1];
    strb = &string[1];

    va_start(ap, form);

    for (p = form; *p; p++) {
        if (*p != '%') {
            *strp++ = *p;
            continue;
        }

        switch (*++p) {
            case 'd':
                ival = va_arg(ap, int);
                sprintf(strp, "%d", ival);
                while (*++strp);
                break;
            case 'x':
                ival = va_arg(ap, int);
                sprintf(strp, "%x", ival);
                while (*++strp);
                break;
            case 'f':
                dval = va_arg(ap, double);
                sprintf(strp, "%f", dval);
                while (*++strp);
                break;
            case 's':
                for (sval = va_arg(ap, char*); *sval; sval++)
                    *strp++ = *sval;
                break;
            default:
                *strp++ = *p;
                break;
        }
    }

    va_end(ap);

    string[0] = strp - strb;
    DebugStr((Str255) string);
}





+++++++++++++++++++++++++++

From: [e-mail] (BoBoRamDos)
Date: 2 Dec 92 20:56:21 GMT
Organization: Reed College, Portland, OR

Perhaps I'm missing something, but seems to be roughly equivalent, but much
less elegant than a snippet someone posted some months ago and which is also
quite useful.  Unfortunately I can't remember where this came from, but it
sure is nice:

void vdebugstr(char* format,...) {
        char buff[257];
        va_list arglist;
        vs_start(arglist,format);
        vsprintf(buff,format,arglist);
        va_end(arglist);
        DebugStr(c2pstr(buff));
}

cheers,
bobo              In seeking the unattainable,
[e-mail]            simplicity only gets in the way.
Ask not what's inside your head but what your head's inside of. - W. Mace

+++++++++++++++++++++++++++

From: [e-mail] (Patrick C. Beard)
Date: 4 Dec 92 01:14:20 GMT
Organization: Department of Computer Science, University of California, Davis


Here's a much shorter version I have been using for eons:

/*
    dprintf.c

    by Patrick C. Beard.
*/

#include <stdarg.h>
#include <stdio.h>

int dprintf(const char* format, ...)
{
    va_list args;
    static char str[256];
    int count;

    va_start(args, format);
    count = vsprintf(str, format, args);
    va_end(args);
    DebugStr(c2pstr(str));
    return count;
}

Let the library do the work, I say.

// Patrick C. Beard
// Department of Computer Science, U. C. Davis
// [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik )
Date: 4 Dec 92 22:50:13 GMT
Organization: Apple

In article <[e-mail]>, [e-mail]
(Patrick C. Beard) wrote:
> Here's a much shorter version I have been using for eons:
>
> /*
>     dprintf.c
>
>     by Patrick C. Beard.
> */
>
> #include <stdarg.h>
> #include <stdio.h>
>
> int dprintf(const char* format, ...)
> {
>     va_list args;
>     static char str[256];
>     int count;
>
>     va_start(args, format);
>     count = vsprintf(str, format, args);
>     va_end(args);
>     DebugStr(c2pstr(str));
>     return count;
> }

Yeah, agree, the only issue is that you drop down somewhere far
beyond the actual point where the assert or something similar
triggered the print to DebugStr (due to the library calls). This
is why I have a lightweight assert that calls DebugStr directly,
and a heavy weight va_args assert for more information printing.

Kent
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Tom Dowdy)
Date: 9 Dec 92 21:29:41 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (David
Peterson) wrote:
> With this dandy new MBPrintf routine you can make up printf style diagnostic
> messages and have them show up in MacsBug correctly interpreted and formatted.

Maybe I'm missing something that yours does that mine doesn't - but this
routine is much simpler and does the same thing.  (Goeff Coco, if he's
out there anyplace, is the person to thank for originally writing this)

void debugprintf(char *sFormat, ...)
/*
    Take a printf style list of args, pass them on and debugstr them.
    Call as you would printf.
*/
{
    Str255        sOut;
    va_list        pArgs;

    va_start(pArgs, sFormat);
    vsprintf(sOut, sFormat, pArgs);
    c2pstr(sOut);

    DebugStr(sOut);

} // debugprintf


 Tom Dowdy                 Internet:  [e-mail]
 Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

From: [e-mail] (Andrew E Page)
Subject: Adding Comm to an Application
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 19 Nov 1992 14:21:27 GMT


   I've just picked up a client who wishes to add modem communications
to an application.  They're currently accomplishing the task with
terminal applications and terminal scripts.  They would like to cut
out the need for the terminal program and have the communications done
from within the application.
   I know that eventually that they should go to a remote access
protocol, and I will be steering future work in that direction.
However, for the time being they just want to simplify their
current application.


    My Major question is thus:

   1)   Just use the serial driver, and standard modem techniques.


   2)   Use the Sys 7  CommToolbox, connection manager, file transfer
        manager etc.  Probably a bit harder from what I've read
        thus far, but will make the migration to true networking
        easier down the road.


   3)   A Third alternative.

- --
Andrew E. Page   (Warrior Poet) |   Decision and Effort The Archer and Arrow
Mac Consultant                  |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 24 Nov 92 16:21:59 GMT
Organization: Qualcomm, Inc.

In article <[e-mail]>, [e-mail] (Andrew E Page)
wrote:
>    2)   Use the Sys 7  CommToolbox, connection manager, file transfer
>         manager etc.  Probably a bit harder from what I've read
>         thus far, but will make the migration to true networking
>         easier down the road.

Using the CTB will be EASIER, not harder, than driving the serial ports
yourself, unless you intend to be very, very simple-minded about it.

It's also a lot more flexible in terms of what kinds of connections you can
make (though somewhat less flexible in terms of any given kind of
connection).

Use the CTB.  You will regret that less often than you will regret doing
your own.  :-)

- --
Steve Dorner, Qualcomm, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Chris Spiral Catfish Tate)
Date: 25 Nov 92 12:35:53 GMT
Organization: Computer Systems Laboratory, DCRT, NIH

In article <sdorner-241192101852@0.0.0.0>, [e-mail] (Steve Dorner) writes:
>
>Using the CTB will be EASIER, not harder, than driving the serial ports
>yourself, unless you intend to be very, very simple-minded about it.
>
>It's also a lot more flexible in terms of what kinds of connections you can
>make (though somewhat less flexible in terms of any given kind of
>connection).

Does the CTB support a reliable TCP/IP tool yet?  Last I heard it didn't, and
it's kept us from using it at all (since the Internet side of our app is
basically more important than the modem side).

Also, I seem to recall that there are licensing issues with providing MacTCP
along with your application; something about having to agree to take
responsibility for supporting fixes etc. to *MacTCP* as well as your own
product.  It's essentially preventing any government-funded product from
being distributed along with MacTCP.

- ------------------------------------------------------------------------------
Christopher Tate             | The Leadfoot Collection, Continued:
Management System Designers  |     * Hot Rod Lincoln (Commander Cody)
                             |     * The Man's Too Strong (Dire Straits)
[e-mail]    |     * Sunshine of Your Love (Cream)

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Wed, 25 Nov 92 12:54:03 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer,comp.sys.mac.comm), [e-mail] (Chris Spiral Catfish Tate) writes:
> Does the CTB support a reliable TCP/IP tool yet?  Last I heard it didn't, and
> it's kept us from using it at all (since the Internet side of our app is
> basically more important than the modem side).

Get "TGE TCP Tool" from ftp.msen.com in /pub/vendor/ice.
This is a CTB MacTCP Tool. It is still a little limited,
but it does handle most of what people want.


tim endres - [e-mail]

Register your company in the Internet Business Pages!
 ...send email to "[e-mail]" for details...

USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Piet Saslawsky)
Date: 25 Nov 92 21:05:13 GMT
Organization: Advanced Software Concepts

In article <[e-mail]> Chris Spiral Catfish
Tate, [e-mail] writes:
>Does the CTB support a reliable TCP/IP tool yet?  Last I heard it
didn't, and
>it's kept us from using it at all (since the Internet side of our app is
>basically more important than the modem side).

Not reliable ???  Well... just try our TCPack. It supports Telnet in both
directions : receive (of course !) and send (this may be useful for
XMODEM file transfers). It also includes a complete support for the
Scripting Interface, which can be used to configure all the IP parameters
: security, time-to-live, precedence or ip-options. Are also included a
FTP server and full support of Domain Name Resolver (hosts file &
server). If you want to try it, a demo version is available on
sumex-aim.stanford.edu as "/info-mac/demo/asc-ctb-tools.hqx". You may try
it with our application "5PM", also available at the same place.

Piet Saslawsky

+-------------------------------------+-------------------------------+
| Advanced Software Concepts (France) | Open Connect Systems (Dallas) |
| email: [e-mail] | email: [e-mail]         |
| voice: (33) 93 24 76 00             | voice: [phone]         |
+-------------------------------------+-------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Adm Scott Bronson)
Date: 6 Dec 92 06:46:52 GMT

In article <sdorner-241192101852@0.0.0.0>, [e-mail] (Steve Dorner) writes:
>
>Using the CTB will be EASIER, not harder, than driving the serial ports
>yourself, unless you intend to be very, very simple-minded about it.

Two months ago, I put the finishing touches on an application whose sole
purpose was to log into a well-known incredibly hard-to-use database and
make it a lot easier to download info.  To save others from going through
the agony that I did, I'll tell you briefly what happened.

My colleage/friend of mine and I accepted the contract to build this.
To help draw up specs for this project, I bought Inside the Mac Comm
Toolbox and saw how incredibly easy it was to add communications to
an app.  Besides, since we were going to use the CTB, the user could
telnet to the database, or some other nifty way of connectiong that may
be available in the future.

Our first problem was how incredibly long it takes for the Apple Modem
Tool to synchronously connect to a modem.  I performed a huge kludge/
workaround making it look like we were open and transferring data
when the connection was still being opened asynchronously (our clients
would not stand for taking that long simply to connect to the database--
after all, no other comm program takes that long).

Then, wes noticed that the error code returned by a tool often failed
to indicate what sort of error actually happened.  In fact, they were
downright misleading.  When you get cmNotOpen, cmUserCancel, cmNotSupported,
or cmNoRequestPending, don't tear your hair out like I did if the error
does not have anything to do with the error code.

It is a minor annoyance to have to reboot after every ExitToShell.  This
can make debugging sessions looong and arduous.  I devised my own
workaround, but this behavior left a bad taste in my mouth.  It looks
to me like sloppy programming.  I mean, no other Macintosh managers
(that I know about) fail so gracelessly on an ES.

The Comm Toolbox allocates about 200K in handles whenever it opens
a connection, and locks them down smack dab in the middle of your
heap.  Makes no effort to HLockHi or any sort of courtesly like that.
This was a MAJOR problem for us because we were doing a lot of
loading and purging of scripts and windows, and we would run into
a ton of out of memory errors even though there was plenty of free
memory--the comm toolbox was just fragmenting the heck out of it.

Finally, the Apple Modem Tool would freeze occasionally during a heavy
transfer using a Teleport 2400/Sendfax modem.  The Teleport would show
data still coming in, the computer would still operate fine, but the
tool would just quit sending the data to us.  This was the straw that
broke the camel's back.

Two days before a major demo of the product, we were still getting these
freezes.  We tried the Hayes Modem tool, but there was some problem
there (I forget what it was) and the CCL Modem Tool, but that didn't
allow a 7-bit data path.  I saved the day (no applause, please) by
spending two days and nights putting AT commands on top of the Serial
Tool, and surprisingly getting it to work.  The demo went without a hitch.

Fully fed up, I rewrote our app almost from the ground up, writing
the CTB clean out of it.  Turns out it took a *shorter* time to write
nd debug routines to talk directly to the serial port, including
searching and acting on the incoming data stream, than it did to
write the CTB routines.  We were now opening the connection in a
reasonable amount of time, our error messages were totally accurate,
and our app was down to needing 150K of memory.

So, unless you've got memory and time to spare, and unless you're
programming for a vertical market where error messages don't have to
matter, be wary of the CTB.  It may have improved since my experience
with it and more reliable tools may have come out--I haven't used it
since we put the finishing touches on this contract.  But, make your
decision carefully--it may end up costing as dearly as it did us.

    - Scott

ObHack: When converting the Serial Tool to drive modems, we needed
to put our interface on top of its configuration dialog.  Using CM
custom choose, I was able to hide some items of the dialog and move
and resize others until it looked exactly like the dialog we wanted.
Really made me glad I was programming a Macintosh; without DITLs, we
would have been sunk.

PS: if you would like more info or clarification, please write.  I
don't hate the comm toolbox.  I just had a really hard time getting
it to do what I wanted, and found in the end that just doing it using
the serial calls was easier in the end.

+++++++++++++++++++++++++++

From: [e-mail] (Edan Shalev)
Date: 7 Dec 92 07:58:28 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Im a fairly new mac programmer and I have a question regarding
the CommToolBox...  Im writing a term program which needs to
search incoming data and handle it accordingly.  The searching part
wasnt a problem, i just used CMADDSEARCH and checked refNum's
in the CMSEARCHCALLBACK.  But what I need is the data that
immediatly follows the match in the search.

example:

add a search for "\pabc"
send "abc123" to the terminal
'abc' will match, now read in '123'

CMSEARCHCALLBACK(ConnHandle,Ptr,long)
will give me a Ptr to the last byte in the found search...
so i figured I could do this..

((char *)Ptr)[0] = lastbyte....
((char *)Ptr)[1] = should equal the next byte (in this case '1')

but it doesnt, the search seems be done byte by byte so it doesnt
contain any other data.  How should I go about retrieving the '123'
following the search pattern 'abc'?  should I do another CMREAD in
the callback routine? if so how do i implement it?

thanks alot!

- -Edan

+++++++++++++++++++++++++++

From: [e-mail] (Bas Schulte, Spider)
Date: 7 Dec 92 19:35:50 GMT
Organization: UTexas Mail-to-News Gateway

Dear Scott,

wauw, your posting about the CTB really struck me. About a week
ago, I posted a message describing my experiences with the CTB,
and they're not good!


> To help draw up specs for this project, I bought Inside the
> Mac Comm Toolbox and saw how incredibly easy it was to add
> communications to an app.

That's what I felt too. I had even used the CTB already in some
simple projects, e.g. a graphical app that would dial out to a
Unix host and fetch my mail there. Just fun and play, but I
hadn't had any problems whatsoever.

For my current project, I needed to write a host-like system
and clients that talk to each other over a connection.


> Besides, since we were going to
> use the CTB, the user could telnet to the database, or some
> other nifty way of connectiong that may be available in the
> future.

Yes, that was a real strong point in my motivation for choosing
the CTB. I could offer immediate connectivity with ISDN and
tcp/ip. That was a great pro.


> Then, wes noticed that the error code returned by a tool
> often failed to indicate what sort of error actually happened.

This really drove me crazy at times! The connection should
offer some morde descriptive error information. I believe the
FileTransfer tools do offer a routine for this. Haven't checked
it though. I also feel that when you want to use a connection
in a cmQuiet+cmNoMenus mode (I was using faceless bg apps), the
app should be able to get some info on what's going on. My
problem was that the AMT just wouldn't start answering the
phone! I couldn't figure out what I was doing wrong. I used
cmopen asynchronously, hoping the completion routine would be
called whenever there was a dail-in attempt. Nope. It just
refused to answer! Coincidentally, while cmopen was running, I
tried a WaitNextEvent sleepval of zero instead of 30, and guess
what? It worked! Now tell me the logic here!


> It is a minor annoyance to have to reboot after every ExitToShell.
> This can make debugging sessions looong and arduous.

That was a problem with older versions of the CTB, newer ones
no longer have this problem.


> Finally, the Apple Modem Tool would freeze occasionally during
> a heavy transfer using a Teleport 2400/Sendfax modem.

I didn't have problems at 2400 baud, but I could forget about
v32bis. Filetransfers _always_ failed, unless I used 128 byte
blocks xmodem, of which throughput was _bad_.


> Two days before a major demo of the product, we were still
> getting these freezes.

Tell me about it: I was having these problems the night before
the demo! At the very last minute we used another app for the
actual modem-ing/transferring! Looked a bit clumsy indeed.


> We tried the Hayes Modem tool, but there was some problem
> there

HMT 1.0.2 doesn't support asynchronous open's.


> be wary of the CTB.  It may have improved since my experience
> with it and more reliable tools may have come out

I think your efforts are a while back, so I do think it has
improved. AMT 1.1.1 handles highspeed modems better (well, they
connect at an acceptable speed...), and you can ES safely.
Haven't looked into memory consumption though (not a very
important issue in my project).


I also started to develop my own serial i/o, but after a few
hours sifting through IM 1-6, I felt really bad. I decided to
redesign my apps to normal apps (vs. bg apps), and let the
various tools display their dialogues to see what was going
wrong, and that gave me some more info, and at this moment it
seems to be going smoother. ISDN and tcp/ip connectivity is
such an important issue for me that I'll stay with the CTB,
despite all my problems, and no doubt my future problems.
Hopefully, when the CTB is integrated with the Entreprise
Toolbox it'll get better.

Best regards,

Bas A. Schulte
Creative Links

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: 8 Dec 92 21:23:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Bas Schulte, Spider) writes:
>> We tried the Hayes Modem tool, but there was some problem
>> there

>HMT 1.0.2 doesn't support asynchronous open's.

HMT 1.0.2 also calls setport (even if cmQuiet) which causes a crash
if you are a faceless bg app.  Hayes knows about this and hopefully will
release a version with that problem fixed.

- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | PUI: Programming Under the Influence.

+++++++++++++++++++++++++++

From: [e-mail] (Alexander M. Rosenberg)
Date: 9 Dec 92 23:50:42 GMT
Organization: Hackers Anonymous

In article <[e-mail]> Bas Schulte,
[e-mail] writes:
>> Then, wes noticed that the error code returned by a tool
>> often failed to indicate what sort of error actually happened.
>
>This really drove me crazy at times! The connection should
>offer some morde descriptive error information. I believe the
>FileTransfer tools do offer a routine for this. Haven't checked
>it though. I also feel that when you want to use a connection
>in a cmQuiet+cmNoMenus mode (I was using faceless bg apps), the
>app should be able to get some info on what's going on. My
>problem was that the AMT just wouldn't start answering the
>phone! I couldn't figure out what I was doing wrong. I used
>cmopen asynchronously, hoping the completion routine would be
>called whenever there was a dail-in attempt. Nope. It just
>refused to answer! Coincidentally, while cmopen was running, I
>tried a WaitNextEvent sleepval of zero instead of 30, and guess
>what? It worked! Now tell me the logic here!

Unfortunately, the Apple Modem Tool relies on idle messages to process an
async opne/listen. Unless it CMIdle is called often enough, it won't be
able to accomplish that within a timeout. This is near the top of the list
of things to change in the Apple Modem Tool.

>> Finally, the Apple Modem Tool would freeze occasionally during
>> a heavy transfer using a Teleport 2400/Sendfax modem.
>
>I didn't have problems at 2400 baud, but I could forget about
>v32bis. Filetransfers _always_ failed, unless I used 128 byte
>blocks xmodem, of which throughput was _bad_.

It would be a miracle if the 1.0.X version of the XMODEM Tool ever
transferred a file successfully.

>Hopefully, when the CTB is integrated with the Entreprise
>Toolbox it'll get better.

Enter...what?
- ---------------------------------------------------------------------------
- -  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
- -  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
- -  Palo Alto, CA 94301     -                                - Systems     -
- -  [phone]          - Nobody is my employer so       - :-)         -
- -  [phone]          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: Qualcomm, Inc.
Date: Thu, 10 Dec 1992 20:32:13 GMT

In article <scott.723624412@mcl>, [e-mail] (Adm Scott Bronson)
wrote:
> Our first problem was how incredibly long it takes for the Apple Modem
> Tool to synchronously connect to a modem.

Yes, it takes a while.  The Hayes Modem Tool is a little faster.  The HMT
is *much* faster on disconnect, which takes the AMT forever.

> Then, wes noticed that the error code returned by a tool often failed
> to indicate what sort of error actually happened.

This is true; error reporting is very poor back to the parent app.
However, if you turn cmQuiet off, the tools I've used give reasonable
feedback.

> It is a minor annoyance to have to reboot after every ExitToShell.

Again, turning cmQuiet off makes this unnecessary; you get an "override"
button.

> The Comm Toolbox allocates about 200K in handles whenever it opens
> a connection, and locks them down smack dab in the middle of your
> heap.

That's not true, or at least not true all the time.  Eudora typically runs
in a 300K partition, and I'm darn sure that it doesn't have 200K to spare
for CTB use!  40K is more like it.  I've not paid attention to locking.

> Finally, the Apple Modem Tool would freeze occasionally during a heavy
> transfer using a Teleport 2400/Sendfax modem.

I haven't ever experienced anything of the kind.  This may simply have been
your bug.

> Fully fed up, I rewrote our app almost from the ground up, writing
> the CTB clean out of it.  Turns out it took a *shorter* time to write

But now I want to use your program over TCP/IP.  Can I?  (No.)  Ditto for
ADSP.  Ditto for serial ports on NuBus cards or ADB (or are you cheating
and using a little of the CTB?).

> PS: if you would like more info or clarification, please write.  I
> don't hate the comm toolbox.

Personally, I *do* hate it.  Many of the points you raise are indeed valid.
 However, the darn thing is just too useful in spite of its flaws,
especially if you AREN'T writing custom single-purpose software, and don't
want to lock your users into one particular form of connection.  So I grin
and bear it.
- --
Steve Dorner, Qualcomm, Inc.
Why does Apple want to eliminate cheap MacTCP applications?

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: 10 Dec 92 22:58:26 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Steve Dorner) writes:

>In article <scott.723624412@mcl>, [e-mail] (Adm Scott Bronson)
>wrote:
>> Our first problem was how incredibly long it takes for the Apple Modem
>> Tool to synchronously connect to a modem.

>Yes, it takes a while.  The Hayes Modem Tool is a little faster.  The HMT
>is *much* faster on disconnect, which takes the AMT forever.

By observation, the HMT also seems to be able to process reads/writes
faster.  I did not do any benchmarks, but I noticed a visible difference
when I switched from HMT to AMT (I wanted to be able to do asynch opens)

- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | PUI: Programming Under the Influence.

---------------------------

End of C.S.M.P. Digest
**********************